Ситуация: тестирование на М5 и на М1 дает разное количество входов за 1 и тот же период времени. В результате анализа входов выясняется ситуация, что некоторые минутные свечи отсутствуют в данных. Например, отсутствует свеча в 09:49. И все бы ничего, если Вам не надо было войти точно в 9:50.

TS Lab видит, что свечи в 9:49 нет, и не входит на открытии свечи в 9:50. «Не запостил — не было». Вы, задавая вход, как бы задаете свечу закрытия и входите на открытии (надеюсь, правильно объясняю) следующей свечи.
Но если заданной свечи не было, то на следующей Вы не сможете зайти. Вход пропущен. Или выход.

Как решить такую проблему? Ведь она может случиться и в реальности. Ну не будет сделок в течении минуты и что? Куда крестьянину податься?
А если надо будет использовать ещё более мелкий ТФ? что делать там?
Мне представляется, что надо бы формировать виртуальную свечу в заданный момент времени из нескольких периодов времени назад так, чтобы среди этих периодов времени гарантированно была хотя бы одна реальная свеча.

Многие, наверняка, отметили пафосные высказывания одного достойнейшего человека, который за простенького робота, условно «на стохастике», не постеснялся запросить 1,5 миллиона рублей и полгода времени… я и тогда понимал, что это даже не овер-прайс, а нечто более гнусное, а сейчас тем более.

Где же амбула? А амбула, мои уважаемые читатели заключается в том, что, я, который ни разу не программист, причем от слова «совсем», не поленился найти и купить за 300 рублей (да-да, я не шучу ни разу) «болванку» в интернетах. Почему «найти и купить»? Потому что мне нужен был хоть какой-то образец для начала работы))). В результате, за полдня, на этой болванке, простейший индикатор, который выполняет простейшие расчеты, был мной создан на Луа и помещен в Квик. Считает все корректно, хотя из-за незнания синтаксиса многое пришлось делать неэлегантно. Например, вместо того, чтобы брать 1-2 бара назад, мне пришлось сильно переписывать формулы, оперируя тем, что есть под рукой, т.е. средними и пр. Причем львиная доля времени ушла на то, чтобы понять, что «любой чих» (пропущенная запятая, случайно поставленный энтер или разрыв строки) влечет неполадку в работе и потребует ещё полдня на поиск этих «чихов». Так что о «сложности» алгоритма можно составить вполне твердое убеждение))). И что теперь? Моя убежденность в афигевшести запрашивавшего такие бабки только усилилась.

В прошлых 2-х темах мы затронули проблемы, связанные с нерыночными рисками… Например, — разрывы связи, вылеты сервера, перезагрузка операционки, а также внезапные остановки торгов по неизвестным причинам. Желающие могут ознакомится с выводами в соответствующих темах, которые легко найти по тэгу «торговые роботы». Причем некоторые коллеги были настолько любезны, что смогли обобщить обсуждения и сформулировать изящные резюме.

Ныне я предлагаю обсудить решение, связанное с приостановкой торгов по одному или нескольким инструментам.

Вечером 30 августа 2022 года Газпром объявил о новой рекордной выплате дивидендов. В результате, утром 31 августа, на торгах акциями Газпрома было минимум 10 приостановок торгов. Сначала был гэп на открытии, затем неоднократные приостановки торгов.

Что делать в таких случаях?

Если у нас случилась приостановка торгов на время, то как это понять на уровне алгоритма?

Вероятно, можно ввести простое условие об отсутствии тиков по каким-либо  инструментам одновременно, которое будет означать приостановку торгов. И, наоборот, наличие тиков по каким-нибудь другим инструментам из этой же или из другой секции мосбиржи. Тогда, для этого, нужно задавать несколько дополнительных и несвязанных инструментов, по наличию тиков на которых мы будем делать вывод о том, что «это просто приостановка торгов по заданным инструментам». Тогда, если найдется хотя бы один такой проверочный инструмент, по которому продолжают поступать тики, то мы, таким образом, поймем, что у нас есть ситуация простой «приостановки торгов», а не чего-то худшего.

Вместо этого можно было бы сделать систему анализа сообщений, поступающих с биржи или от брокера, но это, вероятно, было бы намного сложнее в реализации.

Мнения? Критика? Предложения?

В прошлой теме о решении проблем с каналами связи, один из пользователей отлично резюмировал в нескольких строках. Вот они:

Если вкратце, то все проблемы каналов связи решаются так:

1. Мало денег — домашний сервер, резервный канал. Мониторим руками, можно какую-нибудь пищалку прикрутить на обрывы. Если сломался внешний контур — значит сидим и ждём пока починят.
2. Есть чутка денег — выносим сервер наружу. Получаем алерты в телегу, реагируем руками.
3. Есть ещё чутка денег — дублирующий сервер к варианту 2, пингуем друг-друга, пингуем из третьего места, пингуем пинговалку, обрабатываем результаты.
4. Есть еще больше денег — всё тоже что и п.2. п.3, но только в биржевой стойке.
5. Проблемы связи с торговой системой к пунктам 1-3: Мониторим коннект, переподключаемся, если есть альтернативные сервера.  Если всё завалилось, то используем альтернативные терминалы, звоним брокеру.
6. Проблемы связи с торговой системой, если завалилась биржа — сидим и смотрим.

В буржуйнете довольно развита система взаимопомощи и обмена информацией о «приколах», создаваемых роботостроителям брокерами и/или биржами. Если кто-то обнаруживает новый «прикол», то почти сразу же выкладывает это в паблик, чтобы уберечь средства других людей от истощения. И лишь у нас каждый стремится спрятать под одеялом свои наработки.

Почему бы нам не создать такую тему и не обменяться мыслями/технологиями/решениями по строительству/созданию почти идеального робота? Я говорю не об алгоритмах – прячьте их сколько хотите – это индивидуальная вещь. Я говорю об общих принципах построения роботов, которые должен применять/учитывать любой роботостроитель.

Для начала предлагаю обсудить способ снижения таких неторговых рисков, как «вылетел сервер», «перезагрузилась ось», т.е. проблемы, связанные с функционированием собственного оборудования.

Разумеется, можно запретить автоматическое обновление операционной системы, но отвергать такой риск мы не можем, как не можем отвергать риск внезапной неисправности чужого  или своего сервера, на котором установлен робот. Мы же, как никак, под санкциями. Можно допустить любое развитие событий.